RFC 1421

Privacy Enhancement for Internet Electronic Mail:

インターネット電子メールのプライバシー強化:

Part I: Message Encryption and Authentication Procedures

パート I: メッセージの暗号化と認証の手順

このメモのステータス

この RFC は、インターネット コミュニティ向けの IAB 標準トラック プロトコルを指定し、改善のための議論と提案を求めます。

このプロトコルの標準化状況とステータスについては、最新版の「IAB 公式プロトコル標準」を参照してください。

このメモの配布は無制限です。

謝辞

この文書は、IRTF のプライバシーとセキュリティ研究グループ (PSRG) および IETF の PEM ワーキング グループの一連の会議の成果です。 この文書への貢献について、PSRG および IETF PEM WG のメンバー、および「pem-dev@tis.com」メーリング リストでの議論に参加したすべての参加者に感謝したいと思います。

1. 概要

本文書は、インターネットにおける電子メール転送のためのプライバシー強化メール（PEM）サービスを提供するために、メッセージの暗号化および認証手順を定義するものです。本文書は、関連する4つのRFCセットの1つとなることを意図しています。本文書で定義される手順は、データ暗号化鍵の暗号化における対称（秘密鍵）および非対称（公開鍵）の両手法を含む、幅広い鍵管理手法との互換性を確保することを目的としています。メッセージテキストの暗号化および／または整合性チェックの計算には、対称暗号の使用が想定されています。RFC 1422は、公開鍵証明書の使用に基づく鍵管理メカニズムのサポートを規定しています。RFC 1423は、本RFCおよびRFC 1422に関連するアルゴリズム、モード、および関連識別子を規定しています。RFC 1424は、これらのサービスをサポートするために構築されている鍵管理インフラストラクチャの紙媒体および電子媒体のフォーマットと手順の詳細を規定しています。

プライバシー強化サービス（機密性、認証、メッセージ完全性保証、発信元否認防止）は、ユーザエージェントレベル以上で、送信元プロセスと受信側プロセス間のエンドツーエンド暗号化技術を用いることで提供されます。エンドポイントまたは中間中継サイトにおけるメッセージ転送システムには、特別な処理要件は課されません。このアプローチにより、他のインターネットエンティティに影響を与えることなく、サイトごとまたはユーザごとにプライバシー強化機能を選択的に組み込むことができます。異機種コンポーネントおよびメール転送機能間の相互運用性がサポートされています。

現在の仕様の適用範囲は、RFC-822テキストメール環境におけるPEM処理手順に限定されており、この用途を示すコンテンツドメイン指示値「RFC822」を定義しています。

PEM機能と他のメッセージング環境（MIMEなど）との統合に関する後続作業が予定されており、別文書または後継文書で対応し、その時点で追加のコンテンツドメイン指示値が定義される予定です。

2. 用語

本RFCでは、説明のために、CCITT勧告に基づくOSI X.400メッセージ処理システムモデルで定義されている用語をいくつか使用しています。このセクションは、OSI MHSモデルに精通していない読者にも用語を明確にするため、(1984) X.400のセクション2.2.1「MHSモデルの説明：概要」の一部を引用しています。

発信者は、ユーザーエージェント（UA）の支援を受けてメッセージを準備します。UAは、メッセージ転送システム（Message transfer System MTS）と対話してメッセージを送信するアプリケーションプロセスです。MTSは、送信されたメッセージを1人以上の受信者UAに配信します。MHサービス要素の一部として標準化されていない、UAのみによって実行される機能は、ローカルUA機能(local UA functions)と呼ばれます。

MTSは、複数のメッセージ転送エージェント（Message Transfer Agents MTAs）で構成されています。MTAは連携してメッセージを中継し、宛先の受信者UAに配信します。UAは、メッセージを宛先の受信者が利用できるようにします。

UAとMTAの集合は、メッセージ処理システム（Message Handling System MHS）と呼ばれます。 MHS とそのすべてのユーザーは、総称してメッセージ処理環境(Message Handling Environment)と呼ばれます。

3. サービス、制約、および影響

本RFCは、インターネット上で転送される電子メールのプライバシーを強化するためのメカニズムを定義する。本RFCで議論される機能は、UAレベル以上に位置する送信元プロセスと受信側プロセス間のエンドツーエンドでプライバシー強化サービスを提供する。PEM処理コンポーネント間の中間中継ポイントで追加または変換されるメッセージフィールドについては、プライバシー強化は提供されない。

送信元が送信メッセージに対してPEM処理を実行することを選択した場合、PEMが提供するすべてのセキュリティサービスはPEMメッセージ本体全体に適用され、PEMメッセージの一部のみへの選択的な適用はサポートされない。認証、整合性、および（非対称鍵管理が採用されている場合）発信元否認防止サービスはすべてのPEMメッセージに適用され、機密性サービスはオプションで選択可能である。

インターネットの多様な構成と利用形態に対応するため、ここで定義される対策は、幅広いインターネットホストおよび利用パラダイムに適用可能である。特に、次の属性に注目する価値があります。

1. このRFCで定義されるメカニズムは、特定のホストやオペレーティングシステムに限定されるものではなく、幅広いシステム間の相互運用性を実現します。すべてのプライバシー強化機能はアプリケーション層で実装されており、下位プロトコル層のプライバシー機能には依存しません。

2. 定義されたメカニズムは、非強化インターネットコンポーネントと互換性があります。プライバシー強化機能はエンドツーエンドで実装されるため、プライバシー強化機能を組み込んでいない中間中継ホストによるメール処理には影響しません。ただし、メッセージの送信者は、メッセージの宛先がプライバシー強化機能を実装しているかどうかを把握しておく必要があります。そうすることで、対応する逆変換を実行できない宛先のメッセージに対して、エンコードや暗号化が実行されることがなくなります。 （本RFCのセクション4.6.1.1.3では、PEMメッセージタイプ（「MIC-CLEAR」）について説明しています。これは、PEM処理能力がなくても読み取り可能でありながら、PEMを備えた受信者によって検証可能な形式で、署名された暗号化されていないPEMメッセージを表します。）

4. 定義されたメカニズムは、幅広い電子メールユーザーエージェント（UA）と互換性があります。インターネットでは、多様なユーザーインターフェースパラダイムを備えた、多種多様な電子メールユーザーエージェントプログラムが使用されています。電子メールのプライバシー強化を可能な限り幅広いユーザーコミュニティに提供するためには、選択されたメカニズムが可能な限り多様な既存のUAプログラムで利用可能である必要があります。パイロット実装においては、PEMサービスを提供する各UAに内部的な変更を加えるのではなく、プライバシー強化処理を、様々なUAに適用可能な別個のプログラムに組み込むことが望ましいです。

5. 定義されたメカニズムにより、UA機能が実装されているシステムとは別のパーソナルコンピュータ（PC）上で電子メールのプライバシー強化処理を実行できます。PCの利用拡大と、多くのマルチユーザーシステムにおけるUA実装への信頼度が限られていることを考慮すると、この属性により、多くのユーザーがUAのみを厳密に統合したアプローチよりも高い保証レベルでPEMを処理できるようになります。

6. 定義されたメカニズムは、メーリングリスト（ISO用語では配布リスト）宛ての電子メールのプライバシー保護をサポートします。

7. このRFCで定義されたメカニズムは、手動による事前配布、対称暗号に基づく集中型鍵配布、RFC 1422に準拠した公開鍵証明書の使用など（ただしこれらに限定されません）を含む、様々な鍵管理手法と互換性があります。マルチキャストメッセージの受信者ごとに異なる鍵管理メカニズムを使用できます。2つのPEM実装を相互運用するには、共通の鍵管理メカニズムを共有する必要があります。 RFC 1422 で定義されたメカニズムのサポートが強く推奨されます。

可能な限り広範囲のインターネット ホストおよびメール システムへの適用性を実現し、インターネット全体にわたる事前の広範な変更を必要とせずにパイロット実装とテストを容易にするために、この RFC で指定される機能セットの選択には次の設計原則が適用されました。

1. 本RFCの対策はエンドポイントでの実装に限定され、既存のメールプロトコルの変更やメッセージトランスポートシステム（SMTPサーバーなど）への統合を必要とすることなく、ユーザーエージェント（UA）レベル以上の既存のインターネットメールプロトコルとの統合が容易です。

2. サポートされている対策は、ユーザーの機能を制限するのではなく、強化するものです。ローカルユーザーによるソフトウェアの改ざんからソフトウェアを保護する整合性機能を組み込んだ信頼できる実装は、一般的には想定できません。PEM処理が適用されていないメッセージをユーザーが任意に送信することを防ぐメカニズムは想定されていません。そのような機能がない場合、ユーザーの行動に制限（ユーザー間アクセス制御など）を課すよりも、ユーザーサービスを強化する機能（ユーザー間トラフィックの保護と認証など）を提供する方が実現可能と思われます。

3. サポートされている対策は、幅広いユーザーコミュニティに重要かつ具体的なメリットをもたらすように選択された機能に重点を置いています。最も重要なサービス セットに集中することで、最小限の実装作業で提供できるプライバシーの付加価値を最大化することを目指しています。

これらの原則に基づき、以下の機能が提供されます。

1. 開示保護、

2. 発信者の真正性、

3. メッセージ完全性対策、および

4. (非対称鍵管理が使用されている場合) 発信元の否認防止

しかし、以下のプライバシー関連の懸念事項には対処されていません。

1. アクセス制御

2. トラフィックフローの機密性

3. アドレスリストの正確性

4. ルーティング制御

5. 複数のユーザーによるPCの偶発的な連続再利用に関する問題

6. メッセージ受信の保証と受信の否認不能性

7. 確認応答とそれが参照するメッセージの自動関連付け

8. メッセージ重複検出、リプレイ防止、またはその他のストリーム指向サービス

4. メッセージの処理

4.1 メッセージ処理の概要

このサブセクションでは、電子メールのプライバシー強化処理に含まれる構成要素と処理手順の概要を説明します。以降のサブセクションでは、手順をより詳細に定義します。

4.1.1 鍵の種類

PEM伝送をサポートするために、2階層の鍵階層が使用されます。

1. データ暗号化鍵（DEK）は、メッセージテキストの暗号化と、（複数の代替アルゴリズムから特定のアルゴリズムを選択して）メッセージ整合性チェック（MIC）量の計算に使用されます。非対称鍵管理環境では、DEKは機密性が適用されたPEMメッセージ内のMICの署名表現を暗号化するためにも使用されます。DEKは送信メッセージごとに個別に生成されるため、PEM伝送をサポートするためにDEKを事前に配布する必要はありません。

2. 交換鍵（IK）は、メッセージ内で伝送されるDEKを暗号化するために使用されます。通常、一定期間内に特定の送信者から特定の受信者に送信されるすべてのメッセージには、同じIKが使用されます。伝送される各メッセージには、メッセージの暗号化および／またはMIC計算に使用されるDEKの表現が含まれており、指定された受信者ごとに個別のIKで暗号化されています。この表現は、送信者IDフィールドと受信者IDフィールド（対称型と非対称型を区別するために異なる形式で定義されています）に関連付けられており、各受信者は、これらのフィールドを使用して、その受信者が使用するDEKおよび／またはMICの暗号化に使用されたIKを識別できます。適切なIKが与えられれば、受信者は対応する送信されたDEK表現を復号化し、メッセージテキストの復号化および／またはMIC検証に必要なDEKを生成できます。IKの定義は、DEK暗号化に対称暗号が使用されるか非対称暗号が使用されるかによって異なります。

2a. DEK暗号化に対称暗号が使用される場合、IKは送信者と受信者の間で共有される単一の対称鍵です。この場合、送信用のMICとDEKの暗号化に同じIKが使用されます。対称IKを完全に修飾するには、送信者と受信者に関連付けられたバージョン/有効期限情報とIA IDを連結する必要があります。

4.1.2 処理手順

PEMメッセージのカプセル化されたヘッダーには、1つ以上のOriginator-IDフィールドおよび/または「Originator-Certificate:」フィールドが含まれており、受信者にメッセージ処理に使用されるIKの識別情報を提供します。メッセージのすべてのOriginator-IDフィールドおよび/または「Originator-Certificate:」フィールドは、同一のプリンシパルに対応するものとみなされます。このようなフィールドを複数含めることができる機能は、異なる受信者による処理に異なる鍵、アルゴリズム、および／または認証パスが必要となる可能性に対応します。メッセージに、非対称鍵管理が採用されている受信者と対称鍵管理が採用されている受信者が含まれる場合、各受信者セットの前に個別の Originator-ID または「Originator-Certificate:」フィールドが配置されます。

対称鍵方式の場合、受信者ごとのIKコンポーネントは、個別に指定された受信者それぞれに適用され、ENCRYPTED、MIC-ONLY、およびMIC-CLEARメッセージの作成に使用されます。対応する「Recipient-ID-Symmetric:」フィールドは、直前の「Originator-ID-Symmetric:」フィールドのコンテキストで解釈され、各IKを識別するために使用されます。非対称鍵方式の場合、受信者ごとのIKコンポーネントはENCRYPTEDメッセージにのみ適用され、送信元固有のヘッダー要素とは独立しており、「Recipient-ID-Asymmetric:」フィールドによって識別されます。各Recipient-IDフィールドの後には「Key-Info:」フィールドが続き、指定された受信者に適したIKで暗号化されたメッセージのDEKが転送されます。

特定の受信者に対して対称鍵管理が使用される場合、対応する「Recipient-ID-Symmetric:」フィールドに続く「Key-Info:」フィールドは、受信者のIKで暗号化されたメッセージの計算済みMICも転送します。非対称鍵管理が使用される場合、「Originator-ID-Asymmetric:」または「Originator-Certificate:」フィールドに関連付けられた「MIC-Info:」フィールドには、送信者の秘密鍵を用いて非対称署名されたメッセージのMICが含まれます。PEMメッセージがENCRYPTEDタイプ（本RFCのセクション4.6.1.1.1で定義）の場合、非対称署名されたMICは、「MIC-Info:」フィールドに格納される前に、メッセージテキストの暗号化に使用されたものと同じDEK、アルゴリズム、暗号化モード、およびその他の暗号パラメータを用いて対称暗号化されます。

4.1.2.1 処理手順

暗号化されたメッセージテキストを汎用的に伝送可能な形式で表現し、ある種類のホストコンピュータで暗号化されたメッセージを別の種類のホストコンピュータで復号できるようにするため、4段階の変換手順が採用されています。平文メッセージは、ホストのネイティブな文字セットと行表現を用いたローカル形式で受信されます。ローカル形式は、メッセージテキストのSMTP間表現と同等と定義される標準的なメッセージテキスト表現に変換されます。この標準的な表現は、MIC計算ステップ（ENCRYPTED、MIC-ONLY、およびMIC-CLEARメッセージに適用）および暗号化プロセス（ENCRYPTEDメッセージのみに適用）への入力となります。

ENCRYPTED PEMメッセージの場合、暗号化アルゴリズムの要件に従って正規表現にパディングが施され、このパディングされた正規表現が暗号化されます。暗号化されたテキスト（ENCRYPTEDメッセージの場合）またはパディングされていない正規表現（MIC-ONLYメッセージの場合）は、印刷可能な形式にエンコードされます。印刷可能な形式は、サイト間で普遍的に表現可能であり、MTSエンティティ内およびエンティティ間の処理によって混乱しないよう選択された限定的な文字セットで構成されます。MIC-CLEAR PEMメッセージでは、印刷可能なエンコード手順は省略されます。

前の処理手順の出力は、暗号制御情報を含む一連のヘッダーフィールドと結合されます。結果として得られたPEMメッセージは、電子メールシステムに渡され、送信メッセージのテキスト部分に含まれます。PEMメッセージがMTSメッセージのテキスト部分全体で構成される必要はありません。これにより、PEMで保護された情報に（保護されていない）注釈を付加することができます。複数のPEMメッセージ（およびPEMメッセージ境界外の関連する保護されていないテキスト）を、上位レベルのPEMメッセージのカプセル化されたテキスト内に表現することも可能です。PEMメッセージ署名は、非対称鍵管理が採用されている場合は転送可能です。機密性が適用されたPEMメッセージの承認された受信者は、転送のためにそのメッセージを署名付きで暗号化されていない形式に縮小するか、後続の送信のためにそのメッセージを再暗号化することができます。

PEMメッセージを受信すると、カプセル化されたヘッダー内の暗号制御フィールドは、承認された各受信者が受信したメッセージテキストのMIC検証と復号化を実行するために必要な情報を提供します。ENCRYPTEDメッセージおよびMIC-ONLYメッセージの場合、印刷可能なエンコードはビット文字列に変換されます。送信メッセージの暗号化された部分は復号化されます。MICが検証されます。その後、受信側のPEMプロセスは、正規表現を適切なローカル形式に変換します。

4.1.2.2 エラーケース

構文的に有効でありながらMICエラーが発生するPEMメッセージは、攻撃の試みや偽造メッセージに起因する可能性があるため、特別な懸念事項となります。そのため、コンテンツの真正性と整合性が保証できないことを最初に示し、その後、ユーザーからそのような警告に対する肯定的な確認を得ることなく、その内容を受信ユーザーに表示することは適切ではありません。 MIC-CLEAR メッセージ (この RFC のセクション 4.6.1.1.3 で説明) では、このようなメッセージでの MIC 障害が他の PEM メッセージ タイプに当てはまるものよりも広範囲の無害な原因で発生する可能性があるため、特別な懸念が生じます。

4.2 暗号化アルゴリズム、モード、およびパラメータ

本RFCで定義されるメカニズムには、RFC 1423で規定される対称メッセージ暗号化アルゴリズムおよびモードで要求される場合、機密性サービスが適用されるPEMメッセージに暗号パラメータ（擬似乱数初期化ベクトル（IV）など）を伝送するための機能が組み込まれています。

特定の操作では、伝送のためにDEK、MIC、およびデジタル署名をIKで暗号化する必要があります。ヘッダー機能は、暗号化に使用されるIKのモードを示します。RFC 1423は、暗号化アルゴリズムとモードの識別子、および鍵暗号化処理に必要な最小限のサポート要件を規定しています。

RFC 1422は、本文書で定義されるメッセージ処理手順をサポートするために、CCITT勧告X.509に基づく証明書ベースの非対称鍵管理手順を規定しています。RFC 1422で定義されている鍵管理アプローチのサポートを強く推奨します。適切な対称鍵管理キー（IK）が事前に配布されていれば、このメッセージ処理手順は対称鍵管理と併用することもできますが、現在、そのような対称鍵管理キー（IK）の鍵配布手順を規定したRFCはありません。

4.3 プライバシー強化メッセージ変換

4.3.1 制約

SMTP送信用のメッセージを準備するには、以下の要件を満たす必要があります。

1. すべての文字は7ビットASCII文字セットのメンバーである必要があります。

2. 文字ペア<CR><LF>で区切られたテキスト行の長さは、1000文字以下である必要があります。

3. 文字列 <CR><LF>.<CR><LF> はメッセージの終わりを示すため、メッセージの終わりより前のテキストには出現してはなりません。

EBCDICをネイティブ文字セットとするシステムでSMTPサーバーが行う変換は、EBCDICからASCIIへの変換が情報損失を伴うため、さらに深刻な影響を及ぼします。原理的には、SMTP間の標準ASCIIメッセージ表現とローカルフォーマット間の変換関数マッピングは、SMTPサーバーからUAに移行し、SMTPサーバーがその変換を行わないように指示する手段があれば可能です。しかし、このアプローチには大きな欠点があります。内部ファイル（メールボックスなど）のフォーマットが、それらが存在するシステムで使用されているネイティブ形式と互換性がなくなるのです。さらに、メールは現在とは異なる表現でSMTPに渡されるため、SMTPサーバーへの変更も必要になります。

4.3.2 アプローチ

中間変換が発生する可能性のある環境全体でPEMをサポートするためのアプローチは、システムのネイティブ文字セットに関係なく、PEM UA全体で統一的に表現可能なメールのエンコーディングを定義することです。このエンコード形式は（特定のPEMメッセージタイプにおいて）、送信者から受信者へのメール送信テキストを表現するために使用されますが、MTSヘッダーや、PEM UA間で制御情報を伝送するために挿入されるカプセル化ヘッダーには適用されません。このエンコードの特性により、送信者と受信者のUA間で想定される変換によって、エンコードされたメッセージが宛先で正しくデコードされることが妨げられることはありません。

以下の4つのサブセクションで説明する4つの変換手順は、送信PEMメッセージ処理に適用されます。

4.3.2.1 ステップ1：ローカル形式 Local Form

このステップは、PEMメッセージタイプENCRYPTED、MIC-ONLY、およびMIC-CLEARに適用されます。メッセージテキストはシステムのネイティブ文字セットで作成され、行はローカル規則に従って区切られます。

4.3.2.2 ステップ2：正規化形式 Canonical Form

PEM正規化は、メッセージテキストがASCII文字セットと「<CR><LF>」行区切りで表現されることを保証しますが、RFC 821のセクション4.5.2で説明されているドットスタッフィング変換は実行しません。メッセージは暗号化前に標準の文字セットと表現形式に変換されるため、転送されたPEMメッセージは、あらゆる種類の宛先ホストコンピュータで復号化され、そのMICが検証されます。メッセージを宛先固有のローカル形式に変換するために必要な変換を行う前に、復号化と MIC 検証が実行されます。

4.3.2.3 ステップ3：認証と暗号化

認証処理は、PEMメッセージタイプENCRYPTED、MIC-ONLY、およびMIC-CLEARに適用できます。正規形は、選択されたMIC計算アルゴリズムに入力され、メッセージの整合性チェック量を計算します。MIC計算アルゴリズムに送信される前に正規形にパディングは追加されませんが、一部のMICアルゴリズムはMICの計算中に独自のパディングを適用します。

4.3.2.4 ステップ4：印刷可能なエンコーディング

この印刷可能なエンコーディングステップは、PEMメッセージタイプENCRYPTEDおよびMIC-ONLYに適用されます。セクション4.6で引用されているように、特定のPEMカプセル化ヘッダーフィールド値の表現にも同じ処理が用いられます。ステップ3で得られたビット列は、左から右へと処理を進めていくと、すべてのサイトで普遍的に表現可能な文字にエンコードされますが、必ずしも同じビットパターンになるとは限りません（例えば、文字「E」はASCIIベースのシステムでは16進数の45、EBCDICベースのシステムでは16進数のC5で表現されますが、2つの表現のローカルな意味は同等です）。

国際アルファベットIA5の64文字のサブセットが使用され、印刷可能な文字ごとに6ビットで表現できます。 （提案された文字のサブセットは、IA5とASCIIで同一に表現されます。）文字「=」は、印字可能なエンコード手順におけるパディングに使用される特別な処理関数を表します。

PEMメッセージのカプセル化されたテキストを表現するために、エンコード関数の出力は（ローカルな規則に従って）テキスト行に区切られます。最終行を除く各行はちょうど64文字の印字可能文字を含み、最終行は64文字以下の印字可能文字を含みます。（この行の長さは容易に印字可能であり、SMTPの1000文字の送信行長制限を満たすことが保証されています。）この折り返し要件は、エンコード手順がPEMヘッダーフィールドの量を表現するために使用される場合には適用されません。セクション4.6では、PEMカプセル化ヘッダーフィールドの折り返しについて説明します。

エンコード処理は、24ビットの入力ビットのグループを、エンコードされた4文字の出力文字列として表現します。ステップ3の出力から抽出された24ビットの入力グループを左から右へ順に処理し、各6ビットグループは64個の印刷可能文字の配列へのインデックスとして使用されます。インデックスで参照される文字が出力文字列に配置されます。表1に示されているこれらの文字は、普遍的に表現できるように選択されており、SMTPにとって特に重要な文字（例： "."、"<CR>"、"<LF>"）は含まれていません。

メッセージの末尾の入力グループで利用可能なビット数が24ビット未満の場合、特別な処理が実行されます。完全なエンコード・クォンタムは常にメッセージの末尾で完了します。入力グループで利用可能なビット数が24ビット未満の場合、6ビットのグループを整数個形成するために、（右側に）ゼロビットが追加されます。実際の入力データを表すために必要のない出力文字位置は、文字「=」に設定されます。正規化された出力はすべてオクテットの整数倍であるため、以下のケースのみが発生します。(1) エンコード入力の最終クォンタムが24ビットの整数倍である場合。この場合、エンコード出力の最終単位は「=」パディングなしの4文字の整数倍になります。(2) エンコード入力の最終クォンタムがちょうど8ビットである場合。この場合、エンコード出力の最終単位は2文字とそれに続く2つの「=」パディング文字になります。(3) エンコード入力の最終クォンタムがちょうど16ビットである場合。この場合、エンコード出力の最終単位は3文字とそれに続く1つの「=」パディング文字になります。

table:表1 印刷可能なエンコーディング文字

値 符号 値 符号 値 符号 値 符号

0 A 17 R 34 i 51 z

1 B 18 S 35 j 52 0

2 C 19 T 36 k 53 1

3 D 20 U 37 l 54 2

4 E 21 V 38 m 55 3

5 F 22 W 39 n 56 4

6 G 23 X 40 o 57 5

7 H 24 Y 41 p 58 6

8 I 25 Z 42 q 59 7

9 J 26 a 43 r 60 8

10 K 27 b 44 s 61 9

11 L 28 c 45 t 62 +

12 M 29 d 46 u 63 /

13 N 30 e 47 v

14 O 31 f 48 w (pad) =

15 P 32 g 49 x

16 Q 33 h 50 y

Printable Encoding Characters

4.3.2.5 変換の概要

要約すると、送信メッセージは以下の一連の変換（または、一部のPEMメッセージタイプではそのサブセット）を受けます。

Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))

受信PEMメッセージを処理するために、逆の順序で逆の変換が実行されます。

Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

ローカル形式と、メッセージを正規形式に変換する関数は、送信元システムと受信側システム間で異なっていても、情報の損失は発生しないことに注意してください。

(つづく)